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0.  ABSTRACT: 


This  paper  describes  the  motivation,  design,  implementation,  and 
some  preliminary  performance  characteristics  of  BIGMAC  II,  a  macro  definition 
capability  for  creating  language  enhancers  and  translators.  BIGMAC  en¬ 
ables  the  user  to  specify  transformations  through  STREX,  a  FORTRAN-1  ike 
language,  which  enables  the  specification  of  macros  which  are  then  used 
to  interpretively  alter  incoming  programs.  BIGMAC  is  specially  adapted  to 
the  processing  of  FORTRAN  programs.  This  paper  shows  how  it  can  be  used 
as  a  deprocedurizer  (or  flatterer),  a  dialect-to-dialect  translator,  a 
portability  and  version  control  aid,  and  a  device  for  creating  language 
enhancements  as  sophisticated  as  new  control  structures  and  abstract 
data  types. 


I »  BACKGROJND  AND  MOTIVATION  FOR  PRODUCING  BIGMAC  II 

Over  the  past  several  years  a  significant  number  of  software  analysis 
tools  have  been  produced  by  the  University  of  Colorado  Software  Validation 
Group.  These  tools  have  at  least  initially  been  largely  directed  towards  the 
needs  of  the  Mathematical  Software  community.  Hence  they  have  been  designed  to 
be  portable  over  a  wide  range  of  machines  and  to  analyze  programs  written  in 
FORTRAN.  These  two  considerations  have  led  us  to  code  our  tools  in  FORTRAN.  As 
a  result  we  have  1)  had  good  success  in  readily  rehosting  our  tools  on  a  variety 
of  machines  and  2)  been  able  to  use  our  tools  to  analyze  themselves,  thereby 
increasing  our  confidence  in  them. 

Through  this  considerable  experience  with  FORTRAN,  we  have  come  to  deeply 
understand  some  of  the  significant  shortcomings  of  this  language.  As  tool 
implementors  we  have  chafed  at  the  absence  of  such  features  as  flexible  control 
constructs  and  powerful  data  aggregation  capabilities.  Yet  as  creators  of 
portable  tools  for  producing  mathematical  software  we  felt  a  deep  commitment 
to  FORTRAN,  the  lingua  franca  of  that  community.  In  addition  we  believe  that 
FORTRAN  is,  perhaps  with  the  exception  of  COBOL,  the  most  widely  available, 
most  nearly  standardized  of  all  high  level  languages,  thereby  giving  it  the 
best  prospects  as  a  basis  for  porting  programs.  We  also  found  that  newer 
languages,  such  as  Pascal,  which  offered  superior  control  and  data  aggregation 
facilities  usually  had  drawbacks  of  their  own.  For  example,  Pascal's  block 
structure  is  an  obstacle  to  independent  recompilation  of  subprocedures.  This 
is  a  serious  problem  during  the  development  of  large  tools  such  as  our  DAVE 
system  [0F76,  F:076]. 

Pulled  by  these  conflicting  considerations  we  have  chosen  a  course  taken 
by  many  others  before  us  —  namely  to  enhance  the  FORTRAN  language  in  the  ways 
necessary  to  facilitate  our  work.  A  large  number  of  FORTRAN  preprocessors  have 
been  built  to  enhance  FORTRAN  by  the  creation  of  more  powerful  control  constructs. 
We  were  concerned  more  with  the  need  for  flexibly  defining  and  accessing  powerful 
data  aggregates.  Because  the  preprocessors  we  studied  did  not  offer  significant 
capabilities  of  this  sort,  we  constructed  a  system  of  our  own  [0CS73].  This 
capability  enabled  us  to  define  a  rather  limited  class  of  structured  data  types 
and  access  them  from  our  standard  FORTRAN  source  text.  The  implementation  de¬ 
tails  of  these  data  objects  were  hidden  by  our  data  structuring  capability,  thus 
enabling  us  to  alter  our  data  structures  without  the  need  to  alter  the  source 
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text  which  accessed  them.  This  capability  proved  most  useful,  enabling  us  to 
construct  our  prototype  DAVE  tool  with  a  minimum  amount  of  trauma. 

A  serious  weakness  of  this  capability  is  that  it  conceals  the  imple¬ 
mentation  details  of  the  data  structures  through  the  use  of  layers  of  sub¬ 
routines.  Although  quite  effective  in  concealing  details,  this  technique 
proves  quite  costly  in  execution  time,  necessitating  the  invocation  of  numerous 
subroutines  for  each  data  access. 

Because  of  this  difficulty  we  turned  to  the  consideration  of  a  macro  cap¬ 
ability.  Our  first  goal  was  to  build  a  capability  which  could  deprocedurize 
or  "flatten"  our  code  by  substituting  inline  the  texts  of  subroutines  in  place 
of  the  subroutine  invocations.  We  conceived  of  the  subroutine  text  as  being  a 
sort  of  macro  definition  and  the  subroutine  call  as  being  a  parameterized 
macro  invocation.  We  produced  a  prototype  capability  of  this  sort  and  success¬ 
fully  used  it  to  flatten  the  source  code  for  our  DAVE  system. 

According  to  our  measurements  we  gained  an  improvement  in  execution 
time  of  up  to  50%  by  flattening  only  a  small  number  of  frequently  executed  sub¬ 
program  invocations.  We  then  turned  our  attention  to  building  a  more  general 
macro  processor  to  enable  substantial,  flexible  enhancements  to  FORTRAN.  The 
key  to  doing  this  was  allowing  the  user  to  define  new  source  language  statements 
by  declarations  in  the  macro  language.  Thus,  for  example,  superior  control  flow 
constructs  such  as  CASE,  IF_JHEN__ELSE,  and  DOJIHILE  can  readily  be  added  to 
FORTRAN  by  declaring  them  to  be  new  statements  whose  semantics  are  established 
by  means  of  the  text  of  the  macros  which  define  them. 

The  macro  processor  we  created  is  called  BIGMAC  II  for  historical  and 
humorous  reasons.  Perhaps  the  most  important  capability  which  BIGMAC  offers 
js  the  capability  for  creating  and  accessing  powerful  data  aggregates  while 
hiding  their  implementation  details,  thereby  adding  to  FORTRAN  true  abstract 
data  type  capabilities.  This  is  achieved  by  considering  data  structure 
declaration  statements  to  be  Fortran  language  augmentations  and  data 
structure  accessing  constructs  to  be  new  language  operators.  The  definitions 
of  the  declaration  and  accessing  constructs  are  made  through  macro  definitions. 
As  shall  be  shown  these  definitions  can  (indeed  must)  share  implementation 
details  among  themselves.  These  details  remain  invisible  to  the  source 
code.  Thus  there  is  complete  freedom  to  create  and  alter  the  implementations 
of  data  aggregates  beyond  the  sight  and  control  of  the  FORTRAN  source 
language  coder.  This  inability  to  see  or  access  implementation  details 
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qualifies  this  data  aggregate  capability  as  an  abstract  data  type  definition 
facility  in  the  classical  sense  [LZ75]. 

BIGMAC  also  facilitates  the  porting  of  FORTRAN  programs,  an  important 
consideration  for  tool  developers.  Although,  as  already  noted,  FORTRAN  is 
a  widespread,  standardized  language,  it  is  not  entirely  free  of 

portability  problems.  Numerous  dialects  of  the  language  exist,  offering  a 
variety  of  capabilities  for  handling  such  constructs  as  text  strings,  and 

multiple  precision  numeric  quantities.  These  differences  are  particularly 
vexing  to  the  writer  of  analytic  tools  for  mathematical  software,  as  he  must 
be  concerned  with  both  the  manipulation  of  source  text  and  the  correct 
analysis  of  code  dealing  with  all  possible  numeric  data  types.  A  possible, 
but  unsatisfactory,  solution  is  to  create  a  family  of  versions  of  the  tool 
program,  each  intended  for  a  different  host  compiler.  The  difficulty  here 
is  that  each  must  be  maintained  and,  unless  extraordinary  care  is  taken, 
each  assumes  a  character  of  its  own  and  incompatibilities  between  different 
versions  arise.  The  usual  strategy  is  to  write  the  preponderant  majority 
of  the  program  in  a  portable  subset  of  FORTRAN,  such  as  PFORT  [Ryder76]  and 
quarantine  compiler  dependencies  to  a  very  small  body  of  code  which  must  then 
be  recoded  for  every  new  host  compiler.  This  approach  has  been  widely  used 
with  success  but  still  has  its  drawbacks.  The  compiler  dependent  code  is 
usually  written  as  a  set  of  low  level  subroutines.  Hence  it  usually  is 
frequently  invoked,  always  at  the  undesirable  cost  of  subroutine  invocations. 

In  addition  it  still  necessitates  the  creation  and  maintenance  of  a  family 
of  programs  with  the  attendant  multiplication  of  effort  and  potential  for 
drift. 

Through  the  use  of  BIGMAC,  a  single  master  copy  of  program  text  can  be 
■maintained  and  targeted  for  the  different  host  machines  by  translating  it  with 
different  sets  of  macros  designed  to  adapt  the  master  copy  to  the  idiosyncrasies 
of  the  different  host  compilers.  This  approach  has  been  pursued  in  a  limited 
way  [BM77]  with  good  success.  Our  intention  is  to  use  BIGMAC  to  combine  this 
notion  with  the  capabilities  for  creating  advanced  data  and  control  constructs, 
thereby  enabling  us  to  code  in  a  very  powerful,  highlevel  FORTRAN-1  ike  language, 
yet  still  maintain  a  set  of  completely  consistent  FORTRAN-source  language 
versions  merely  by  performing  macro  expansions  (see  Figure  1). 


FIGUE  1;  BIGTOC  AS  A  Porting  Mechanism 
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The  remainder  of  this  paper  discusses  the  particular  macro  capabilities 
which  we  have  implemented  in  BIGMAC.  The  salient  features  of  these  capabilities 
are  flexibility,  power,  and  the  ease  with  which  BIGMAC  can  be  used  by  FORTRAN 
programmers.  Much  of  the  flexibility  of  BIGMAC  derives  solely  from  the  fact  that 
it  is  a  macro  capability.  The  user  is  free  to  declare  any  macros  and  define 
them  in  any  way  he  chooses.  Hence  new  statement  types  can  be  added  to  the 
language  and  arbitrary  subroutines  can  be  expanded  as  in-line  code  in  an 
arbitrary  way.  Additional  flexibility  derives  from  the  fact  that  existing 
statements  from  standard  FORTRAN  can  be  redefined  according  to  the  dictates  of 
user  specified  macros.  Thus,  for  example,  the  syntax  and  semantics  of  exist¬ 
ing  FORTRAN  statements  can  be  expanded  to  encompass  new  operators.  Examples  of 
this  will  be  shown  in  the  following  section. 

The  power  of  BIGMAC  derives  in  large  measure  from  the  fact  that  it  provides 
for  more  than  a  straightforward  in  situ  text  insertion  capability.  Macro 
definitions  are  parameterized,  and  source  text  lines  are  considered  to  consist 
of  the  macro  identifier  and  an  argument  string.  Macro  definition  bodies  can 
be  constructed  to  analyze  the  argument  strings  and  to  use  them  as  the  basis 
for  the  construction  of  appropriate  object  text.  Thus,  the  object  text 
produced  may  vary  considerably  from  one  invocation  to  the  next.  In  addition 
a  macro  definition  body  is  capable  of  creating  object  text  and  specifying 
its  insertion  in  any  of  three  places,  corresponding  to  the  site  of  the  macro 
invocation,  a  location  within  the  declaration  block  of  the  invoking  program 
unit,  and  a  location  completely  outside  of  the  invoking  program  unit.  Hence 
a  macro  invocation  can  cause  the  creation  of  entire  utility  routines  and 
FORTRAN  declarations,  as  well  as  executable  code.  This  is  the  primary  vehicle 
for  creating  and  hiding  the  implementation  of  powerful  data  aggregates. 

Finally  it  is  important  to  note  that  care  has  been  taken  to  assure  that 
the  macro  definition  process  is  not  beyond  the  grasp  of  FORTRAN  programmers. 

Macros  are  themselves  defined  by  means  of  code  written  in  STREX,  a  string 
extended  FORTRAN  dialect.  Thus  it  is  expected  that  FORTRAN  programmers  could 
readily  learn  to  produce  their  own  macros. 
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1 1 •  BIGMAG  technical  DESCRIPTION: 

^ •  BIGMAC  Capabilities : 

BIGMAC  is  a  general  purpose  translation  system  for  FORTRAN  software.  The 
ksy  theoretical  concepts  behind  BIGMAC  are  those  of  syntax  directed  translation 
transducers  [Baker78,KP80] .  To  configure  a  specific  translator,  one 
submits  a  context  free  grammar  [AU72]  and  a  set  of  tree  macros  to  the  BIGMAC  sys¬ 
tem.  The  rewrite  rules  of  the  grammar  determine  the  language  that  the  translator 
will  accept  as  input.  The  tree  macros  are  programs  that  accomplish  the  desired 
translation  by  modifying  the  derivation  tree  [AII72]  of  the  input.  Each  rewrite 
rule  in  the  grammar  is  coupled  with  a  tree  macro.  The  grammar  and  tree  ipacros 
that  configure  a  translator  are  termed  a  translation  specification. 

Once  a  translator  has  been  configured,  it  will  transform  a  segment  of 
text  as  follows.  If  the  submitted  text  is  not  in  the  language  generated  by 
the  translator  s  grammar  then  errors  are  issued  where  appropriate  and  the  text 
is  output  unmodified.  Otherwise  a  derivation  tree  for  the  text  is  built  where 
each  vertex  in  the  tree  corresponds  to  a  rewrite  rule  and  hence  a  tree  macro. 

These  tree  macros  are  invoked  when  their  associated  vertices  are  reached  in  a 
traversal  of  the  derivation  tree.  This  activity  results  in  a  modification  of 
the  derivation  tree.  The  string  derived  by  this  modified  tree  is  then  output 
as  the  desired  translation. 

It  is  important  to  note  that  the  idea  of  producing  a  source  code  trans¬ 
formation  system  is  not  new  with  this  effort.  Boyle  has  produced  a  system, 

TAMPR  [BM77],  based  on  the  notion  of  supporting  user  specified,  correctness¬ 
preserving  tree  transformations.  Our  own  work  differs  from  TAMPR  most  strik¬ 
ingly  in  that  it  is  specially  adapted  to  the  needs  of  the  FORTRAN  community. 

Thus  the  user  specifies  translations  in  STREX,  a  language  comfortably  close  to 
FORTRAN.  In  addition,  many  primitives  are  supplied  to  facilitate  the  transfor¬ 
mation  of  FORTRAN  programs.  We  conjecture  that  these  primitives  also  give  to 
the  BIGMAC  system  mare  power  than- is  available  through  TAMPR. 

BIGMAC  has  a  built-in  FORTRAN  grammar.  Thus  BIGMAC  translators  will  always 
accept  FORTRAN  software  as  input.  This  built-in  grammar  can  be  augmented  at 
the  statement  and  operator  levels  by  the  placement  of  additional  rewrite  rules 
in  a  translation  specification.  Tree  macros  must  accompany  these  additional 
rewrite  rules  but  their  presence  is  optional  for  the  built-in  FORTRAN  rewrite 
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rules.  Whenever  a  tree  macro  is  not  present  in  a  translation  specification  it 
is  assumed  to  be  the  null  program.  Thus  the  translator  configured  from  the 
empty  translation  specification  will  accept  FORTRAN  code  as  input  and  return 
the  same  code  as  output.  This  augmentation  approach  to  translation  specifica¬ 
tions  is  in  keeping  with  BIGMAC's  role  as  a  FORTRAN  software  tool.  BIGMAC 
translators  will  accept  a  specified  superset  of  FORTRAN  as  input  and  perform 
a  translation  based  on  a  selected  subset  of  the  rewrite  rules. 

The  target  or  output  code  of  a  BIGMAC  translation  is  expected  to  be  FORTRAN, 
although  any  other  language  (e.g.,  assembler,  Pascal)  could  be  output.  To 
facilitate  the  production  of  FORTRAN  as  output,  there  are  a  number  of  special 
primitives  available  to  the  tree  macro  writer  for  this  purpose.  The  efficiency 
of  translated  code  is  dependent  on  the  coding  effort  put  into  the  tree  macros. 

Good  but  not  optimal  results  can  usually  be  obtained  with  little  effort. 

As  already  noted,  the  BIGMAC  system  can  be  used  to  configure  translators 
for  a  variety  of  tasks.  In  the  paragraphs  below,  we  describe  in  a  general 
way  how  BIGMAC  can  be  used  to  create  some  of  these  different  types  of  translators. 

At  the  highest  level  BIGMAC  can  be  used  as  a  compiler-compiler  [AU72].  In 
order  to  do  so,  one  must  compose  a  translation  specification  encompassing  the 
desired  language  and  transformation.  In  this  case,  the  built-in  FORTRAN  grammar 
is  ignored.  As  an  example  of  this,  BIGMAC  is  currently  being  used  to  build  a 
compiler  for  a  PASCAL-1  ike  language  which  produces  FORTRAN  as  target  code. 

BIGMAC  can  be  used  to  extend  the  FORTRAN  language  in  several  ways.  For 
example,  new  data  abstractions  [Morris79,  LZ75]  such  as  a  STRING  or  BIT  VECTOR 
data  type  can  be  added  to  the  language.  This  requires  the  introduction  of 
at  least  one  new  declarative  statement  and  a  number  of  operators  and  execut¬ 
able  statements  for  manipulating  the  data  type.  The  rewrite  rules  for  these 
new  forms  and  tree  macros  which  translate  them  into  standard  FORTRAN  are  all 
that  is  needed  to  accomplish  the  extension.  New  control  structures  such  as 
IF__THEN_ELSE  and  D0__WHILE  can  be  added  by  the  introduction  of  rewirte  rules 
and  tree  macros  for  these  new  statements.  The  tree  programs  necessary  for 
these  forms  are  particularly  simple  and  thus  a  preprocessor  having  the  power 
of  IFTRAN  [IFTRAN75],  for  example,  can  readily  be  configured. 

The  need  for  a  program  flattener  for  a  program  coded  in  FORTRAN  has 
already  been  discussed.  A  BIGMAC  translator  for  performing  this  flattening 
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can  be  configured  simply  by  specifying  the  appropriate  tree  programs  for  those 
FORTRAN  rewrite  rules  which  correspond  to  the  subroutine  calls  and  function 
references  which  are  to  be  flattened. 

The  utility  of  a  macro  processor  as  a  portability  aid  has  also  been 

discussed.  The  use  of  BIGMAC  to  accomplish  this  will  be  discussed  in  detail 
shortly. 


B.  The  Use  of  BIGMAC 

The  design  of  BIGMAC  envisions  two  classes  of  users.  A  small  group  of 
BIGMAC  experts,  called  macro  writers,  are  responsible  for  configuring  trans¬ 
lators.  Only  macro  writers  need  to  know  how  to  compose  translation  specifi¬ 
cations.  The  second  user  class  is  called  the  using  community  and  consists 
of  those  groups  that  use  any  of  the  translators  provided  by  the  macro  writers. 
The  members  of  the  software  using  community  need  only  know  how  to  program 
code  which  utilizes  any  of  a  translator's  enhancements. 

The  structure  of  BTGMAC  is  depicted  in  Figure  2.  The  system  consist^ 

0"^  ^  translation  compiler  and  an  expander.  A  translation  specification  is 
submitted  to  the  translation  compiler  which  results  in  the  creation  of  a 
translation  module.  This  module  consists  of  parsing  tables  and  object  modules 
for  the  tree  macros.  The  expander  when  coupled  with  a  translation  module,  forms 
a  translator  which  takes  a  user's  input  and  transforms  it  accordingly. 

The  translation  specification  and  the  input  have  been  separated  in  the 
BIGMAC  system  to  accomodate  the  distinction  between  macro  writers  and  the  using 
community.  Furthermore,  a  translation  specification  is  compiled  because  it 
is  expected  to  be  used  repeatedly.  To  interpret  complex  specifications 
for  each  translation  would  be  extremely  inefficient. 

Consider  as  an  example  the  approach  to  porting  illustrated  in  Figure  1. 
This  approach  can  be  implemented  by  using  BIGMAC  as  follows.  A  group  of  macro 

writers  must  first  compose  a  translation  specification  to  support  a  high-level 
FORTRAN  dialect  as  requested  by  the  using  community.  They  also  write  specifica¬ 
tions  that  configure  porting  translators  for  host  machines  1,  2,  and  3.  Call 
these  specifications  HLF-TS,  Pl-TS,  P2-TS,  and  P3-TS  respectively.  Using  the 
BIGMAC  translation  compiler,  the  macro  writers  form  the  translation  modules 

HLF-TM,  Pl-TM,  P2-TM,  and  P3-TM  as  follows.* 

Trans 1  at ionjCompiler(S=HLF-TS ,M=HLF-TM) 
TranslationjCompiler(S=Pi-TS ,M=Pi-TM)  for  i  =  1,2,3. 


*The  functional  notation,  ‘ Trans lation_Compiler  (S=<filej^>,M=<file2>) ' 

denotes  an  application  of  the  translation  compiler,  where  the  translation 
specification  is  <file^>  and  the  resulting  translation  module  is  <file2>. 
Similarly,  in  the  statement  'Expander(I=<filej^>,M=<file2>,0=<file2>) 

<filej^>  is  the  input,  <file2>  translation  module,  and  <file2>  the  result¬ 
ing  output. 


Translation 

Compiler 
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Wow  suppose  that  a  development  group  in  the  using  community  has  written 
code  for  an  application  system  in  the  Fortran  dialect  they  specified  previously. 
Call  the  code  SC-HLF.  To  run  this  code  on  the  local  machine  requires  invoking 
the  appropriate  BTGMAC  translator  and  compiling  the  result  with  the  local 
FORTRAN  compiler.  This  procedure  is  expressed  in  functional  notation  as: 

Expander (I=SC-HLF,M=HLF-TM,0=SC-F0R) 

Fortran__Compi  1  er  ( I=SC-F0R  ,0=SC-BI  N ) 

Once  the  development  group's  software  is  ready  for  porting  to  machine  i  the 
appropriate  porting  translator  is  used. 

Expander( I=SC-F0R,M=Pi-TM,0=SC-F0Ri ) 

The  output,  SC-FORi,  is  then  sent  to  host  machine  i,  where  it  is  subsequently 
compiled  by  that  machine's  FORTRAN  compiler.  Thus  by  writing  the  four  trans¬ 
lation  specifications  above,  the  macro  writers  have  created  an  environment  for 
the  software  using  community  in  which  a  high-level  FORTRAN  can  be  employed  and 
1n  which  porting  to  three  additional  machines  is  automatic. 
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C.  Implementation  of  BIGMAC 

In  Figure  3,  the  structure  and  interaction  of  a  translation  module  and 
the  BIGMAC  expander  are  shown  in  detail.  The  expander  performs  a  translation 
in  three  passes.  In  the  first  pass,  the  front-end  builds  a  derivation  tree 
of  the  input  by  consulting  the  syntax  tables  of  the  translation  module.  This 
derivation  tree  is  output  as  the  first  image.  In  the  second  pass,  the 
evaluator  traverses  the  derivation  tree  calling  the  tree  macros  of  the  trans¬ 
lation  module  when  appropriate.  This  activity  results  in  a  modification  of 
the  derivation  tree  which  constitutes  the  second  image.  In  the  last  pass, 
the  formatter  produces  as  the  final  output  the  string  yielded  by  the  modified 
derivation  tree. 

Up  to  this  point  a  rather  abstract  model  of  BIGMAC‘s  operation  has  been 
given,  BIGMAC* s  behavior  has  been  described  in  terms  of  context-free  grammars, 
derivation  trees,  and  tree  programs.  A  system  which  tries  to  embrace  the 
full  generality  of  these  concepts,  would  undoubtedly  be  highly  inefficient. 

One  of  the  main  design  aims  of  BIGMAC  was  to  simplify  these  concepts  in  such  a 
way  that  they  still  provide  a  powerful  translation  capability  for  which  an 
efficient  implementation  is,  nevertheless,  possible.  These  simplifications 
are  described  in  the  paragraphs  below. 

,C.l.  Front  End  &  Syntax  Tables: 

A  grave  space  problem  arises  if  one  attempts  to  build  a  derivation 

tree  for  the  entire  input  stream  in  a  straightforward  manner.  The  BTSMAC 
system  simplifies  matters  by  processing  the  input  text  and  inter-pass  images 
in  sequential  forward  scans,  one  statement  at  a  time.  A  statement  is  defined  in 
the  FORTRAN  sense  of  the  word,  that  is,  as  a  72- character  line,  optionally 
followed  by  up  to  nineteen  66-character  continuation  lines.  There  are  assumed 
to  be  four  types  of  statements  -  header,  specification,  executable,  and  tail  - 
which  must  be  grouped  into  program  units  according  to  the  following  syntax. 

<Input>  ^  <Program_Unit>* 

<Program_Unit>  X-  <Header>  <Specifications>*  <Executable>*  <Tail> 

There  is  also  a  neutral  type  statement  whose  occurrence  in  the  input  is  un¬ 
restricted.  This  organization  supports  the  FORTRAN  notion  of  program  units 
or  modules,  but  other  organizations  are  possible  by  declaring  all  statements 
to  be  neutral  and  placing  the  burden  of  sequence  checking  on  the  tree  programs. 


'ransutor  in  Detail 
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The  range  of  syntactic  augmentation  allowed  in  a  translation  specification 
is  restricted  to  the  extent  that  a  simple  LL-parsing  [AU72]  scheme  suffices 
in  syntactically  decomposing  the  input.  In  this  scheme,  look-ahead  is  very 
rarely  required  and  usually  involves  the  scanning  of  just  one  or  two  characters. 
The  front-end  builds  a  derivation  tree  for  each  statement  and  outputs  these 
in  sequence.  The  front-end  also  detects  any  syntactic  errors. 

For  each  program  unit,  the  front-end  builds  a  symbol  table  of  the  labels 
and  identifiers  that  occur  in  the  unit.  The  front-end  also  builds  a  global 
symbol  table  of  all  those  identifiers  whose  context  determines  that  their  scope 
is  global  (e.g.,  subroutine  names,  common  block  name,  etc.).  These  tables  are 
used  to  generate  unique  identifiers  and  labels  by  the  tree  macros  in  the 
evaluation  pass.  They  are  also  used  for  associating  attributes  or  descriptors 
with  each  identifier. 

C . 2  Evaluator: 

The  BIGMAC  evaluator  processes  the  derivation  tree  of  each  statement  in 
a  postorder  traversal.  As  each  vertex  is  traversed,  its  associated  tree  macro, 
if  present,  is  invoked.  Conceptually,  tree  macros  can  be  thought  to  trans¬ 
form  the  derivation  tree  directly.  However,  in  the  BiGMAC,  system  the  mechanisms 
for  text  generation  (modification)  are  quite  simple.  A  tree  macro  can  append 
statements,  semantic  error  messages,  and  comments  to  the  text  stream  at 
several  strategic  locations.  In  this  way,  a  tree  macro  can  generate  side 
effects,  document  them,  and  report  semantic  errors.  A  tree  macro  can  also 
modify  the  derivation  tree  containing  the  invoking  vertex,  v,  as  follows. 

The  tree  macro  can  replace  the  string  currently  yielded  by  v  in  the  derivation 
tree  by  any  string  it  chooses  to  produce.  The  tree  macro  receives  as 
arguments,  the  strings  currently  yielded  by  each  son  of  v  in  the  derivation 
tree.  Figure  4  gives  an  example  of  this  text  substitution  process.  In  Figure  4, 
the  operator  subscripts  are  shown  to  indicate  the  order  of  evaluation  followed. 
Also  note  only  the  operators  Fun  and  +  have  defining  tree  macros.  The  other 
operators  are  evaluated  according  to  the  usual  rules  of  FORTRAN. 

Since  the  simple  text  substitution  scheme  employed  in  the  BIGMAC  system 
deals  only  with  the  strings  yielded  by  derivation  tree  vertices,  a  derivation 
tree  need  never  be  built.  A  simple  text  substitution  algorithm  used  in  many 
of  the  older  macro  processors  [Cole76]  suffices  to  perform  the  desired  trans¬ 
formation  and  only  requires  the  post-order  sequence  of  invoking  vertices.  This 
algorithm  provides  increased  space  and  time  efficiency  especially  when  the 
translation  only  operates  on  a  small  subset  of  the  grammar  rev/rite  rules. 
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C.3  Tree  Macros : 

In  BIGMAC  translation  specifications,  a  tree  macro  is  a  program  unit 
written  in  an  extension  of  FORTRAN  called  STREX  (^ring  Extended)  FORTRAN. 

A  compiler  for  this  extension  of  FORTRAN  was  produced  by  a  bootstrap  of 
the  BIGMAC  utility.  The  STREX  language  supports  a  fQbsB  of  FORTRAN  and  has 
the  following  additional  features  — 

1.  A  STRING  data  type. 

2.  A  HEAP  data  type. 

3.  Text  generation  primitives. 

4.  Symbol  table  primitives. 

5.  Global  and  local  macro  communication  primitives. 

STREX  FORTRAN  supports  all  FORTRAN  constructs  except  for  those  involving 
I/O  or  Hollerith,  Real,  Double  Precision,  or  Complex  data  types  [ANSI66].  The 
additional  features  are  described  below. 

STREX  supports  the  notion  of  a  string  data  type  in  full  generality 
[Elson73].  Simple  variables,  arrays,  and  functions  can  all  be  declared  to 
be  of  type  string.  The  value  of  a  string  variable  may  vary  arbitrarily  in 
length  at  runtime.  At  the  expression  level  strings  can  be  concatenated, 
substrings  can  be  selected,  the  current  length  can  be  queried,  and  strings 
can  be  tested  for  equality.  String  constants  are  denoted  by  a  sequence  of 
characters  enclosed  in  dol lar-signs($) .  At  the  statement  level  string  variables 
can  be  assigned  (by  value)  and  the  replacement  of  a  substring  of  a  string 
variable  is  also  possible.  Strings  are  used  in  features  3,  4,  and  5  above. 

The  STREX  heap  data  type  is  a  vector  of  storage  of  arbitrary  length. 

The  elements  of  the  vector  may  be  any  data  type  including  heap.  In  this  way, 
recursive  structures  such  as  lists  and  trees  can  be  readily  implemented.  The 
type  of  a  vector  element  is  latent;  that  is,  it  may  vary  at  runtime.  Whereas 
assignment  is  by  value  for  all  other  data  types,  assignment  to  a  heap  variable 
changes  the  vector  the  variable  refers  to.  Thus  an  assignment  between  two 
heap  variables,  say  HI  =  H2,  causes  HI  to  refer  to  the  vector  referred  to  by 
H2,  and  H2  becomes  undefined.  There  are  primitives  to  determine  the  length 
of  a  variable's  vector  and  whether  a  variable  is  undefined.  There  are  also 
statements  for  creating  and  freeing  heap  vectors.  Heap  variables  are  used  in 
features  4  and  5, 

The  STREX  language  contains  several  statements  which  append  strings  to  the 
output  text  stream  at  any  of  three  locations.  The  string  expressions  used  in 


these  primitives  are  assumed  to  represent  either  statements ^  comments,  labels, 
or  error  messages  depending  on  the  primitive.  The  three  locations  at  which 
a  string  may  be  appended  are: 

a/  immediately  before  the  statement  currently  being  scanned, 
b/  immediately  before  the  first  executable  statement  of  the 
program  unit  currently  being  scanned, 
c/  immediately  before  the  first  statement  of  the  current  program 
unit. 

These  locations  allow  one  to  generate  side-effects,  additional  specification 
statements,  and  additional  program  units,  respectively.  There  are  expression 
level  primitives  for  generating  identifiers  and  labels  which  are  unique  with 
respect  to  either  the  -global  symbol  table  or  the'Tocal  symbol  table  of  the 
current  program  unit.  These  primitives  return  the  labels  and  identifiers  as 
strings  and  are  used  in  constructing  branches  and  temporary  variables. 

The  symbol  tables  produced  by  BIGMAC's  front  end  are  available  to  the 
macro  writer.  A  heap  variable,  presumably  containing  a  descriptor,  is 
associated  with  each  symbol.  One  can  look  up  a  symbol,  thereby  accessing 
the  symbol's  heap  variable.  This  variable  may  be  accessed  or  modified  according 
to  the  intentions  of  the  macro  writer.  New  symbols  may  be  added  dynamically. 

Tree  macros  can  communicate  to  each  other  in  one  of  two  ways.  Common 

blocks  can  be  included  in  any  tree  macro.  The  extents  of  the  variables  in 
such  a  common  block  are  global  to  the  evaluation  process.  In  this  way, 
global  communication  is  possible  —  any  tree  macro  may  modify  or  access  these 
global  variables.  In  the  event  that  a  son  of  an  invoking  vertex  is  also  an 
invoking  vertex,  the  tree  macro  associated  with  the  son  may  pass  a  heap  vector 
to  the  tree  macro  of  its  father.  This  local  communication  mechanism  is 
accomplished  with  a  pair  of  "pass-catch"  primitives.  This  mechanism  allows 
for  the  bottom-up  propagation  of  synthesized  attributes  (heap  vectors)  [Knuth]. 

C.4  Formatter: 

The  BIGMAC  formatter  preserves,  the  spacing  and  indentation  found  in  the 
input  stream.  This  formatter  has  two  output  ports.  The  primary  output 
contains  the  transformed  text  less  any  comments  or  error  messages.  The  other 
port  is  to  the  printer.  This  output  contains  the  comments  and  error 
messages  and  in  addition  contains  summaries  of  the  tree  macros'  activities. 
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III.  SOME  SIMPLE  BIGMAC  EXAMPLES: 

Two  BIGMAC  examples  are  given  in  the  following  paragraphs.  For  each 
example  the  BIGMAC  translation  specification  is  listed  and  discussed  first. 
The  discussion  is  then  followed  by  a  sample  translation. 

The  first  example  generates  in-line  code  for  the  following  function 
which  computes  the  sum  of  the  elements  of  an  array. 

REAL  FUNCTION  SUM(A,N) 

REAL  A(N) 

SUM  =  0. 

DO  10  I  =  1,N 
10  SUM  =  SUM  +  A(I) 

RETURN 

END 


The  translation  specification  which  will  perform  this  in-lining  consists  of 
one  tree  macro  -- 


1. 

REFERENCE  B  = 

SUM(A,N) 

2. 

STRING  IL,  I, 

L 

3. 

B  =  .GENR. 

4. 

IL  =  .GENI. 

5. 

I  =  .GENI. 

6. 

L  =  .GENL. 

7. 

EXECUTE 

B  *  $  =  0.$ 

8. 

EXECUTE 

IL*$  =  $*N 

9. 

EXECUTE 

$D0  $*L*$ 

10. 

LABEL  L 

11. 

EXECUTE 

$  $  *  B  *  $  = 

12. 

RETURN 

13. 

END 

$*  I  *$  =  1,  $*  IL 


The  header  of  the  tree  macro  (line  1)  indicates  that  the  macro  is  to 
be  activated  for  every  reference  to  SUM  which  has  two  arguments.  The  vari- 
bles  B,  A,  and  N  in  this  statement  are  implicitly  STRING  variables.  The 
value  of  B  when  the  macro  returns  is  the  string  which  replaces  the  reference. 
The  variables  A  and  N  are  passed  to  the  macro  on  entry  and  their  values  are 
the  strings  representing  the  two  arguments  to  SUM.  Line  2  declares  the 
variables  IL,  I,  and  L  to  be  of  type  STRING. 

In  line  3,  the  value  of  B  is  assigned  to  an  implicitly  real  identifier 
which  is  unique  with  respect  to  the  current  program  unit.  Lines  4,  5,  and 
6  have  the  same  effect  except  that  implicit  integer  identifiers  (lines  4  and 
5)  and  labels  (6)  are  generated.  Lines  7  through  11  generate  code  for  the 
function  SUM's  side-effect  and  place  it  immediately  before  the  current 


statement.  Each  of  these  lines  consist  of  the  keyword  EXECUTE  or  LABEL 
followed  by  a  string  expression.  The  characters  between  $-signs  are  string 
constants  and  *  denotes  string  concatenation. 


Suppose  one  submitted  the  following  input  to  the  translator  configured 
from  the  above  translation  specification. 

REAL  A(15),  B(20),  T(5),  SUM 
READ  (INPUT)  (A(I),I=1,15) 

READ  (INPUT)  (B(I),I=1,20) 

DO  10  I  =  1,5 

10  IF(I.NE.5)  T(I)  =  SUM(A,3*  I) +SUM(B,20) 

WRITE  (OUTPUT)  (T(I),I=1,4) 

STOP 

END 

The  output  would  be  as  follows 

REAL  A(15),  B(20),  T(5),  SUM 
READ  (INPUT)  (A(I),I=1,15) 

READ  (OUTPUT)  (B( I ) , 1=1 ,15) 

DO  10  I  =  1,5 

IF(.N0T.(I.NE.5))  GOTO  10 
AOOOOO  =  0. 

100000  =  3  *1 

DO  10000  100001  =  1,100000 

10000  AOOOOO  =  AOOOOO  +  A(IOOOOl) 

AOOOOl  =  0. 

100002  =  20 

DO  10001  100003  =  1,100002 

10001  AOOOOl  =  AOOOOl  +  B( 100003) 

T(I)  =  AOOOOO  +  AOOOOl 

10  CONTINUE  . 

WRITE  (OUTPUT)  (T(I),M,4) 

STOP 

END 


Note  that  the  meaning  of  the  ^  label  10  was  preserved.  The  BIGMAC  front-end 
automatically  preconditions  the  input  code  so  that  the  meaning  of  labels  is 
preserved.  It  also  splits  the  logical  if  statement  so  that  any  text  placed 
"immediately"  before  the  second  clause  of  the  IF  statement  is  guaranteed  to 
be  executed  just  before  the  execution  of  this  clause.  The  code  produced  is 
not  optimal.  A  slightly  more  sophisticated  tree  macro  would  not  generate 
100002  or  100003  or  the  assignment  to  100002. 

The  second  example  illustrates  the  addition  of  an  IF-THEN-ELSE  control 
structure  to  the  FORTRAN  language.  This  requires  the  addition  of  three 
statements  with  the  syntax  -- 
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<statement>  ^  'IF'  <expression>  'THEN' 
^  'ELSE' 

^  'ENDIF' 


The  proper  nesting  of  these  statements  is  enforced.  An  ELSE-statement  refers 
to  the  most  recent  IF-statement.  The  translation  specification  consists  of 
four  tree  macros  and  a  global  block. 


1. 

2. 

3. 

4. 

5. 

6. 

7. 

8. 

9. 

10. 

11. 

12. 

13. 

14. 

15. 

16. 

17. 

18. 

19. 

20. 
21. 
22. 

23. 

24. 

25. 

26. 

27. 

28. 

29. 

30. 

31. 

32. 

33. 

34. 

35. 

36. 

37. 

38. 

39. 

40. 

41. 

42. 

43. 


GLOBAL  PSHD'WN 
HEAP  LABSTK 
END 

STATEMENT/E/  $IF$- . EXP ./A-$THEN$ 

INCLUDE  PSHDWN 
HEAP  H 
STRING  LAB 
LAB  =  .GENL. 

EXECUTE  $IF  (.N0T.($*A*$))  GOTO  $  ^  LAB 
NEW  H(2) 

H(1,.HEP.)  =  LABSTK 
H(2,.STR.)  =  LAB 
LABSTK  =  H 
RETURN 
END 

STATEMENT/E/  $ELSE$ 

INCLUDE  PSHDWN 
STRING  LAB 

IF  (.UNDEF. LABSTK)  GOTO  10 
LAB  =  .GENL. 

EXECUTE  $G0T0$  *  LAB 
LABEL  LABSTK(2,.STR.) 
LABSTK(2,.STR.)  =  LAB 
RETURN 

10  ERROR  $IMPR0PER  NESTINGS 
RETURN 
END 

STATEMENT/E/  $END$-$IF$ 

INCLUDE  PSHDWN 
IF  (.UNDEF. LABSTK)  GOTO  10 
LABEL  LABSTK(2,.STR,) 

LABSTK  =  LABSTK(1,.HEP.) 

RETURN 

10  ERROR  SIMPROPER  NESTINGS 
RETURN 
END 

END  OF  UNIT 

INCLUDE  PSHDWN 

IF  (.UNDEF. LABSTK)  RETURN 

ERROR  SIMPROPER  NESTINGS 

FREE  LABSTK 

RETURN 

END 
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In  lines  1  through  3  a  global  block  called  PSHDWN  is  declared  to  con¬ 
sist  of  the  single  HEAP  variable  LABSTK.  LABSTK  will  be  used  to  implement 
a  pushdown  stack  of  the  labels  being  used  in  the  transformation.  The 
INCLUDE  statements  (lines  5,  17,  29,  and  38)  in  each  of  the  tree  macros 
indicate  that  the  variables  in  the  PSHDWN  global  block  are  to  be  used  by 
these  macros. 

The  first  tree  macro  (lines  4  to  15)  corresponds  to  the  IF-THEN  state¬ 
ment.  In  lines  8  and  9  the  appropriate  conditional  branch  is  generated.  The 
label  used  in  this  branch  is  pushed  onto  the  LABSTK  push  down  stack  in  lines 
10  through  13. 

The  ELSE  tree  macro  (lines  16  to  27)  checks  the  nesting  of  statements 
(line  19)  and  produces  an  error  message  if  appropriate  (line  25).  If  the 
nesting  is  correct  then  a  branch  is  generated  to  tie  off  the  IF-THEN  clause 
and  this  clause's  target  label  is  appended  to  output  (lines  20-22).  The 
ELSE  label  replaces  the  IF-THEN  label  in  the  top  element  of  the  push-down 
stack  (line  23). 

The  END- IF  tree  macro  (lines  28-36)  also  checks  the  nesting  of  statements 
(line  30).  If  there  are  no  errors  then  the  current  target  label  is  appended 
to  the  output  and  the  push-down  stack  is  popped  (lines  31  and  32). 

The  last  tree  macro  (lines  37  to  43)  is  a  special  macro  which  is 
activated  whenever  the  end  of  a  program  unit  is  reached.  This  macro  checks 
the  nesting  of  statements  and  frees  the  push-down  stack. 

Suppose  one  submitted  the  following  input  to  the  translator  configured 
from  this  translation  specification. 


IF  I.NE.0  THEN 
IF  J.NE.0  THEN 

A  =  A+  1  + J 

ELSE 

A  =  A+  I 

ENDIF 

ELSE 

IF  J.NE.0  THEN 
A  =  A  + J 

ENDIF 

ENDIF 


-22 


The  output  would  be  as  follows  -- 


IF  (.NOT.(I.NE.0))  GOTO  10000 
IF(.NOT.(J,NE.0))  GOTO  10001 
A  =  A+  1  + J 
GOTO  10002 

10001  A  =  A+I 

10002  GOTO  10003 

10000  IF  (.NOT.(J.NE.0))  GOTO  10004 
A  =  A  + J 

10004  CONTINUE 

10003  . 


Once  again  the  semantics  of  the  transformation  is  correct  but  not 
optimal.  The  use  of  .NOT.  could  be  folded  in  the  three  IF  statements.  The 
statement  "GOTO  10003"  is  spurious.  A  more  sophisticated  translation 
specification  could  avoid  these  failings. 

This  concludes  the  technical  description  of  BIGMAC.  Appendix  A  contains 
the  grammar  for  STREX  FORTRAN.  Appendix  B  illustrates  an  ambitious  trans¬ 
lator  for  a  bit  vector  data  type. 
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IV.  EXPERIENCES  AND  FUTURE  WORK 

BIGMAC  is  written  in  a  portable  subset  of  FORTRAN  66,  in  which  de¬ 
pendencies  have  been  quarantined  to  a  small  set  of  subprograms.  BIGMAC 
consists  of  10,000  lines  of  source  text.  The  system  requires  45K  words  of 
memory  plus  whatever  space  the  macros  of  a  particular  translation  specifica¬ 
tion  require.  The  following  timing  figures  were  obtained  on  a  CDC  6400. 


Front-end  : 

70 

source  lines/sec. 

Evaluator  : 

90 

II 

Formatter  : 

90 

II 

Total 

Throughput  : 

27 

II 

These  times  were  obtained  with  the  empty  translation  specification  (identity 
translator)  and  thus  provide  an  upper  bound  on  the  performance  of  BIGMAC. 


As  indicated  earlier,  we  produced  the  STREX  compiler  module  of  BIGMAC 
by  a  bootstrapping  operation  utilizing  a  prototype  version  of  BIGMAC.  The 
translation  specification  needed  for  this  bootstrap  involved  a  macro  for 
every  operator  and  statement  in  the  language  and  required  1000  lines  of  STREX 
code.  The  timing  figures  for  the  STREX  compiler  on  the  CDC  6400  are  as  follows 


Front-end 

Evaluator 

Formatter 

Total 

Throughput 
Expansion  Factor 
Macro  Rate 


60  source  lines/sec. 

50 

90  object  lines/sec. 

17  source  lines/sec. 

2.2  object  lines/source  line 

75  macros/sec. 


The  STREX  compiler  is  an  example  of  a  heavily  enhanced  FORTRAN  dialect.  Thus 
the  above  figures  provide  an  approximate  lower  bound  on  BIGMAC 's  performance, 
although  more  complex  enhancements  are  conceivable. 

One  of  the  nice  features  of  BIGMAC  is  illustrated  by  the  STREX  compiler. 
The  utilization  of  a  complete  set  of  macros  allowed  us  to  write  macros  that 
perform  a  complete  semantic  check  of  STREX  code.  Coupled  with  BIGMAC s  in¬ 
herent  syntactic  checking,  this  means  that  the  FORTRAN  object  code  produced 
by  STREX  is  guaranteed  to  be  compilable  FORTRAN.  Thus  error  reporting  is 
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confined  to  the  source  level,  a  feature  not  found  in  many  preprocessing 
systems. 

We  are  currently  in  the  late  stages  of  using  BIGMAC  to  define  a 
translator  capable  of  accepting  as  input  essentially  a  large  subset  of 
PASCAL  and  producing  as  output  essentially  FORTRAN  66.  Simultaneously, 
we  are  using  BIGMAC  to  write  macro  sets  which  will  allow  us  to  port  this 
FORTRAN  code  to  a  modest  range  of  host  compilers.  The  completion  of  these 
translators  will  mark  the  beginning  of  our  efforts  to  use  BIGMAC  as  a 
production  tool.  We  expect  to  use  these  translators  to  simultaneously 
target  a  large  PASCAL  program  to  a  range  of  host  FORTRAN  compilers.  This 
attempt  will  do  much  to  help  us  evaluate  the  practicality  of  this  macro 
approach  as  a  portability  and  version  control  aid. 
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APPENDIX  A:  THE  SYNTAX  OF  STREX  FORTRAN 

An  extended  version  of  Backus  Naur  Form  grammar  rules  will  be  used  to 
describe  the  syntax  of  a  STREX  translation  specification.  Non-terminals 
will  consist  of  the  token '§  name  surrounded  by  angle  brackets,  e.g. 

<ProgramJJnit> 

Terminal  strings  will  be  enclosed  in  single  quotes,  e.g. 

'STRING' 

A  plus  sign  will  be  used  to  compress  several  rules  having  the  same  left-hand 
sides,  e.g. 

<A>  <B>  +  <C>  £  <A>  ■<-  <B> 

<A>  ^  <C> 

A  superscript  star  will  denote  zero  or  more  repit ions,  e.g. 

<A>  ^  <B>*  E  <A>  ^  "  +  <A>.<B> 

Curly  braces  will  be  used  for  bracketing  purposes,  e.g. 

<A>  {<B><C>}*<D>  5  <A>  <D>  +  <B><G><A> 

An  exclamation  mark  will  denote  optional  occurrence,  e.g. 

<A>  -f-  <C>!  £  <A>  ^  '  '+  <C> 

In  STREX  FORTRAN  there  are  four  different  kinds  of  data  types  or  modes  - 

STRING  INTEGER 

HEAP  LOGICAL 

The  semantic  notion  of  data  type  is  included  in  this  grammar  spec¬ 
ification  by  considering  the  above  modes  to  be  attributes  of  the  various 
non-terminals.  For  example,  <IdeSTRING>  asserts  that  the  identifier 
in  question  is  of  mode  STRING.  These  attributes  are  synthesized  in  all 
executable  statements,  and  inherited  in  all  others. 
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I.  PROGRAM  UNIT  LEVEL: 

•k 

<Translation_Specification>  ^  <Program_ljnit> 

■k 

<Program  Unit>  ^  <Header>  {  <Type  Declarations>  +  <Inc1udes>  } 

★ 

<Executable>  <End> 

•k 

+  <Globa1_Header>  <Type_Declarations>  <End> 

<Header>  ^  <Macro_Header>  +  <Subroutine_Header>  +  <Function_Header> 

<Executable>  ^  <Assignment> 

+  <Heap_Anocation> 

+  <Text_Generation> 

+  <Return> 

+  <Continue> 

+  <IF__Statements> 

+  <DO_Statement> 

+  <GO_TO__Statements> 

+  <CALL__Statement> 

+  <Catch_Statement> 

+  <Symbol_Statements> 


II.  STATEMENT  LEVEL: 

A.  Headers: 

<G1oba1_Header>  ^  'GLOBAL'  <Global__Id> 

<Subroutine_Header>  ^  'SUBROUTINE'  <SubJd> 

{  '('  <Jd>  {  <id>  }*  ')■  }1 

<Function__Header>  ^  <T_Jype>  'FUNCTION'  <S1mp1eJdeT„Type> 

'('  <Id>  {  <ld>  }*  ')' 
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<Macro__Header>  <STRING_Temp1ate>  +  <IDENTIFIER__Template> 

+  <0PERAT0R_Tenip1ate>  +  <REFERENCE_Template> 

+  <INV0CATI0N_Template>  +  <SPECIAL_Template> 

+  <STATEMENT_Template> 

<STRING_Template>  'STRING'  <Return_Arg_Id>  '  =  '  '$'  <Arg_Id>  '$' 
<IDENTIFIER_Template>  ^  'IDENTIFIER'  <ReturnJ\rg__Id>  '=' 

{  <Id>  +  <WndJd>  } 

<0PERAT0R_Temp1ate>  -e  'ZOP'  <Return_Arg_Id>  '='  {  <Id>  +  <Wild_Id>  } 

+  'OOP'  <Return_Arg__Id>  '  =  ' 

{  '  +  '  +  {  <l^>  +  <wndjd>  }  } 

<Arg__Id> 

+  'BOP'  <Return__Arg_Id>  '  =  '  <Arg_Id> 

{  <wnd_Id>  '.' 

+  1  l  +  »  +  l_l  4.  1*1  +  lyfl  +  1**1 

+  '.'  <U>  '.'  }  '('  <Int>  ')'  } 

<Arg_Id> 

<REFERENCEJ‘enip1ate>  ^  'REFERENCE'  <Return__ArgJd>  '  =  ' 

{  <WildJd>  •('  <H_WildJd>  ')' 

^  <H_Wnd_Id>  +  <Arg_Id>  <Arg_Id>}  }  ')'} 

<INVOCATION_Jemplate>  ^  'INVOCATION' 

{  <wnd_Id>  '(■  <H__Wild_Id>  ')' 

+  <Id>  '('  {  <H_Wnd_Id>  +  <Arg_Id>  <Arg_Id>}  }  ')'} 

<SPECIALJ'emplate>  ^  {  'START'  +  'END'  }  'OF'  'TEXT' 

+  'START'  'OF'  'UNIT'  '('  <ArgJd>  ')' 

+  'EXIT' 

+  'ENTRY' 


+  'TERMINATION 
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<STATEMENT_Temp1ate>  ^  'STATEMENT'  {  '/'  {  'H'  +  'S'  +  'E'  +  'T'  +  'N'  }  '/'  }! 

•k 

<Arg_Del>  {  <Arg_Del>  } 

<Arg_Del>  ^  <Deliniiter> 

+  <Phrase>  '/'  <Arg_Id> 

+  <H_Phrase>  V'  <!^_Arg_Id> 

<Del1niiter>  '$'  <Char>  '$' 

<Phrase>  MD. '  +  '.GID.'  +  '.REF.'  +  '.STR.'  +  '.INT.'  +  '.EXP.' 
<H__Phrase>  ^  'LIST'  '('  <De1>  {  '-'  <De1>  }*  ' ) ' 

<Del>  ^  <De1imiter>  +  <Phrase>  +  <H  Phrase> 


<Return_Arg_Id>  ^  <Sinip1e_IdeSTRING> 
<Arg_Id>  ^  <Simple_IdeSTRING> 

<H_Arg_Id>  <S1mple__IdsHEAP> 

<wndjd>  ^  <SimpleJdeSTRING> 

<H  Wild  Id>  ^  <SimpTe  IdeHEAP> 


B.  Specifications: 

■k 

<Type__Declarations>  ^  <T_Type>  <RefeT_Jype>  {  <RefeTjrype>  } 

+  <Tjype>  'REFERENCE'  <FunJdeFJ-ype>  {  <FunJdeFJ"ype>  }* 

<T_Jype>  ^  'HEAP'  +  'STRING'  +  'INTEGER'  +  'LOGICAL' 


<Includes>  ^  'INCLUDE'  <G1obal  Id> 
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C.  Executable  Statements: 

<Assignment>  -f-  <VRefESTRING  >  '  =  '  <ExpcSTRING> 

+  <VRef£HEAP>  '='  <ExpeHEAP> 

+  <VRefeINTEGER>  '='  <ExpeINTEGER> 

+  <VRefeLOGICAL>  <ExpeLOGICAL> 

+  <VRefeSTRING>  '('  <ExpeINTEGER>  {  <ExpeINTEGER>  }!  ')' 

'='  <ExpeSTRING> 

<HGap_Anocation>  '.FREE'  <VRefeHEAP> 

+  'NEW  <VRefeHEAP>  '('  <Exp£lNTEGER>  ')' 

<Textj3ieneration>  ^  {  'EXECUTE'  +  'LABEL'  +  'COMMENT'  +  'ERROR'  + 

'DECLARE'  +  'CREATE'  }  <ExpeSTRIN6> 

<Return>  ^  'RETURN'  +  'PASS'  <VRefeHEAP> 

<Continue>  ^  'CONTINUE' 

<IF__Statements>  ^  'IF'  '('  <ExpeLOGICAL>  ')' 

{  <ExecutabIe>^  +  <Labe1>  ','  <LabeI>  <Labe1>  } 

E  An  except  DO_Statenient 

<DO_Statement>  ^  'DO'  <La-be1.>  <Simple__IdeINTEGER>  '  =  ' 

<ExpeINTEGER>  <ExpeINTEGER>  {  <ExpeINTEGER>  }! 

<GO_JO_Statements>  ^  'GO'  'TO'  {  <Labe1> 

+  '('  <Labe1>  <Label>}*  ')'  ','  <IdeINTEGER>  } 

<CALL_Statement>  ^  'CALL'  <Sub_Id>  {  '('  <Exp>  {  ','  <Exp>  }  ')*)!, 

<Catch_Statement>  ^  'CATCH'  {<VRef eSTRING>  +  <FRefeHEAP>  }  'IN'  <RefeHEAP> 
<Symbol_Statements>  ^  'LOOKUP'  {  '('  'GLOBAL'  ')'  }!  <ExpeSTRING>  'IN'  <RefeHEAP> 


D.  End: 


<End>  ^  'END 
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III.  EXPRESSION  LEVEL: 


ExpeB0P(T, ,T2)>  + 

<ExpeT^>  <Bop> 

<ExpeT2> 

Operator 

Precedence 

Type  Rules 

** 

100 

**( INTEGER, INTEGER)  =  INTEGER 

★ 

200 

*(STRING, STRING)  =  STRING 
*{INTEGER, INTEGER)  =  INTEGER 

/ 

200 

/(INTEGER, INTEGER)  =  INTEGER 

+  »- 

300 

+(INTEGER, INTEGER)  = 

-(INTEGER, INTEGER)  =  INTEGER 

.NE.,.EQ. 

400 

.NE.(STRING,STRING)  =. 

•  EQ. (STRING, STRING)  = 

•  NE. (integer, INTEGER)  = 

■EQ. (integer, INTEGER)  =  LOGICAL 

.GT.,.GE., 

.LT.,.LE. 

400 

•GT. (INTEGER, INTEGER)  = 

•GE. (INTEGER, INTEGER)  = 

•LT. (integer, INTEGER)  = 

.LE.( INTEGER, INTEGER)  =  LOGICAL 

.AND., .OR. 

500 

•AND. (LOGICAL, LOGICAL)  = 

•OR. (LOGICAL, LOGICAL)  =  LOGICAL 

<ExpeUOP(T)>  -4-  <Uop>  <ExpeT> 


Operator  Type  Rules 


.eONVER. 

.CONVER.( INTEGER)  =  STRING 

.INTERP. 

•INTERP. (STRING)  =  INTEGER 

.UNDEF. 

•UNDEF. (HEAP+STRING)  =  LOGICAL 

+  »- 

+( INTEGER)  =  -(INTEGER)  =  INTEGER 

.LENGTH. 

•LENGTH. (HEAP+STRING)  =  INTEGER 
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<Exp£T>  <ExpeT>  ' ) ' 

<ExpeSTRING>  ^  '.EMPSTR.'  +  '$'  <Char>'^  '$' 

<ExpeINTEGER>  ^  <Int> 

<ExpeT>  ^  <VRefeT>  +  <FRef^HEAP> 

<ExpgSTRING>  ^  <ExpeSTRING>  '('  <Exp£lNTEGER>  {  <Exp£lNTEGER>  }!  ')' 


IV.  REFERENCE  LEVEL: 

<Ref£T_Type>  ^  <Simple_Id£T_Type> 

+  <ArrayJd£TJ'ype>  '('  <ExpeINTEGER>  {  <ExpeINTEGER>  ‘ ' 

<VRef8T_Jype>  ^  <Ref£T_Type> 

+  <Ref£HEAP>  '(■  <Exp£lNTEGER>  <CoerceT_Jype>  ')' 

<Coerc£HEAP>  '.HEP.' 

<CoerceSTRING>  ^  '.STR.' 

<CoerceINTEGER>  ^  '.INT.' 

<CoerG£LOGICAL>  ^  '.LOG.' 

<FRefeT  Type>  ^  <Fun  IdeT  Type>  '('  <Exp>  {  <Exp>  1  ')' 

I  ~  _  — 

^  E  All  FORTRAN  Intrinsic  functions  on  INTEGERS  and  LOGICALs 
are  supported. 

V.  IDENTIFIER  LEVEL: 

<Simple__Id>  ^  <Id> 

<Array_Id>  ^  <Id> 

<Fun_Id>  ■<-  <Id> 

<Sub  Id>  ^  <Id> 


<GlobaI  Id>  ^  <Id> 
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APPENDIX  B:  A  BI6MAG  TRANSLATOR  FOR  A  BIT-VECTOR  DATA  TYPE 

Many  algorithms  employ  the  notion  of  a  set  whose  underlying  implemanta- 
tion  is  assumed  to  utilize  bit  vectors.  This  provides  the  motivation  for  ex¬ 
tending  the  FORTRAN  language  to  incorporate  a  BIT  VECTOR  data  type  via  a 
BIGMAC  translator.  Such  an  extension  is  described  in  this  appendix. 

We  begin  by  informally  describing  the  syntax  and  semantics  of  the 
augmentation.  Simple  variables  and  arrays  may  be  declared  to  be  of  type 
BIT  VECTOR.  For  example,  the  statement  'BIT  VECT0R(180)  A,B(10)'  declares 
A  to  be  a  bit  vector  of  180  bits,  and  B  to  be  a  10  element  array  whose  elements 
are  bit  vectors  of  180  bits.  Bit  vector  variables  may  be  formal  parameters 
but  not  function  names.  It  was  also  thought  to  be  convenient  to  allow  one 
to  declare  integer  constants.  For  instance, 

CONSTANT  NPROC  =  100 
CONSTANT  NVAR  =  1000 

declares  NVAR  to  be  the  constant  1000  and  NPROC  to  be  the  constant  100. 

These  statements  can  occur  anywhere  within  the  input  and  apply  in  all  sub¬ 
sequent  code.  For  example, 

BIT  VECTOR(NVAR)  LOCAL(NPROC) 

declares  LOCAL  to  be  a  100  element  array  of  1000  bit  bit  vectors. 

Bit  vector  arithmetic  is  performed  with  the  aid  of  a  number  of  binary, 
unary,  and  nullary  operators  with  which  one  can  build  expressions.  These 
bit  vector  operations  are  sketched  in  the  table  below. 


Op 

Precedence 

Type  of  Result 

Meaning 

A.NE.B 

400(lowest) 

LOGICAL 

l\  ^  B 

A.EQ.B 

400 

LOGICAL 

A  =  B 

A. UNION. B 

300 

BIT  VECTOR 

A  u  B 

A. INTER. B 

200 

BIT  VECTOR 

A  n  B 

A.DIFF.B 

lOO(highest) 

BIT  VECTOR 

A  -  B 

.COMP. A 

- 

BIT  VECTOR 

'v  A 

.EMPTY. 

- 

BIT  VECTOR 

13 

.UNIV. 

- 

BIT  VECTOR 

.0 
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For  all  binary  operators,  the  arguments  must  be  bit  vectors  of  the  same  length 
Additional  operators  can  be  supported  as  needed  by  adding  to  the  translation 
specification  which  supports  this  extension  (see  Figure  B2).  A  specific  bit 
of  a  bit  vector  may  be  tested  by  referencing  the  bit's  position.  For  example, 
the  expression  ' (A. INTER.B(l) ) ( 1*3) '  returns  a  logical  value  which  is  true  if 
and  only  if  the  1*3^*^  bits  of  both  A  and  B(l)  are  set.  Bit  vector  expressions 
may  be  actual  arguments  to  a  procedure  invocation. 

Assignment  is  extended  to  include  the  BIT  VECTOR  data  type.  For  example 
the  statement  'B(3)  =  .COMP. A'  assigns  the  bit  vector  value  of  the  expression. 
.COMP. A  to  the  variable  B(3).  In  addition,  individual  bits  can  also  be 
assigned.  For  example,  'B(3)(2)  =  .TRUE.'  sets  the  second  bit  of  B(3)  and 
'B(3)(2)  =  A(2)'  assigns  the  second  bit  of  B(3)  to  the  value  of  the  second 
bit  of  A. 

The  translation  specification  which  supports  this  extension  is  listed  in 
Figure  B2.  The  code  is  quite  lengthy  (approximately  400  lines)  and  thus  will 
not  be  discussed  in  detail.  Instead,  the  nature  of  the  transformation  this 
translation  specification  performs  will  be  discussed  using  the  sample  trans¬ 
lation  in  Figure  B1  as  an  example. 

All  occurrences  of  a  constant  identifier  are  replaced  with  the  constant 
assigned  to  the  identifier.  For  example,  in  Figure  Bl,  'COMMON  /LIST/  LIST, 
LARR(NVAR)'  becomes  'COMMON  /LIST/  LLST,LARR(1000) ' .  All  bit  vector  variables 
are  turned  into  integer  arrays  by  the  addition  of  an  extra  dimension.  The 
size  of  this  dimension  is  the  number  of  words  required  by  a  bit  vector.  The 
specification  in  Figure  B2  is  for  a  CDC  6600  which  has  60  bit  words.  Thus 
the  declaration,  'BIT  VECTOR(NVAR)  TV  becomes  'INTEGER  TV(17)'  where  17 
equals  (NVAR-l)/60+l . 

Any  reference  to  a  bit  vector  variable  within  the  executable  part  of 
a  program  unit,  is  transformed  into  an  augmented  array  reference  where  the 
extra  dimension  is  a  unique  free  variable.  For  example,  a  reference  to  'TP' 
becomes  'TP( 100000)'  and  a  reference  to  'AT(SN)'  becomes  'AT( 100000, SN) ' . 

The  free  variable,  100000,  is  used  as  required  by  the  context  of  the  reference 
For  example,  the  assignment  'AT(SN)  =  TP'  is  transformed  into  the  two  lines 
of  code  ~ 

DO  10004  100000  =  1,2 

AT(iaO000,SN)  =  TP(IOOOOO) 


10004 


By  constructing  a  do  loop  in  which  the  free  variable  is  the  index,  the  assign¬ 
ment  takes  place  word  by  word.  As  another  example  of  the  context  sensitive 
usage  of  the  free  variable,  consider  the  code  generated  for  the  bit  selection 
in  the  statement  'IF  ( .NOT.ATB(SNP)(R))  80  TO  60'  - 

100000  =  (R-l)/60+l 
100001  =  R-(I00000-1)*60 

100005  =  (ATB(I00000,SNP). AND. 100002(100001)). NE.0 
IF(. NOT. 100005)  GO  TO  60 

The  free  variable  pair  (100000,100001)  determine  the  word  and  index  within 
the  word  of  the  selected  bit  R.  100005  is  a  generated  logical  variable  in 
which  the  result  of  the  bit  selection  is  stored.  100002(100001)  is  a  constant 
word  whose  lOOOOl^^  bit  is  set  in  the  block  data  unit  initializing  100002. 

The  free  variable  is  not  bound,  however,  when  forming  bit  vector  ex¬ 
pressions.  For  example,  the  expression  ' LOCAL(P) .DIFF.FORMAL(P) .INTER. OPT(P) ' 
is  transformed  into  ' L0CAL( 100000, P) .AND. .NOT. F0RMAL(I00000,P) .AND. 0PT( 100000, P) ' . 
The  free  variable  is  not  bound  until  a  context  like  the  ones  above  is  reached. 

In  Figure  Bl,  the  expression  is  passed  by  value  to  the  subroutine  LIST  in  the 
statement  'CALL  LIST(LOCAL(P) .DIFF.FORMAL(P) .INTER. OPT(P) ,NVAR) ' .  The  code 
generated  for  this  statement  is  — 

DO  10003  100000  =  1,17 

10003  100003(100000)  =  L0CAL( 100000, P). AND. NOT. F0RMAL( 100000, P. AND. 0PT( 100000, P) 

CALL  LIST(I00003,1000) 

A  unique  bit  vector  variable  100003  is  generated  and  the  value  of  the  expression 
is  assigned  to  it.  100003  is  then  passed  to  LIST  as  an  actual  argument. 

Some  features  of  the  translator  are  not  illustrated  in  Figure  Bl.  The 
constants  .EMPTY,  and  .UNIV.  are  folded  whenever  possible.  That  is,  an  ex¬ 
pression  like  (A. INTER. . EMPTY .) .DIFF.B  is  simplified  to  '.COMP.B'.  Semantic 
errors  such  as  type  incompatibilities  are  detected  and  reported.  For  example, 
the  expression  'TP(SNP) (P) .AND.AT'  is  transformed  into  '**ERR0R**.AND.**ERR0R**' 
as  TP(SNP)  is  not  a  bit  vector  expression  and  AT  is  not  a  logical  expression. 

The  code  generated  is  quite  efficient  but  not  optimal.  In  Figure  Bl, 
only  four  temporary  variables  were  generated  and  occupied  only  22  words  of 
storage.  A  small  amount  of  superfluous  code  is  present.  For  example,  the 


word-index  pair  for  bit  position  V  is  computed  twice  in  the  sequence  of 
statements  — 

TV(V)  =  .TRUE. 

CALL  LIST(LOCAL(P) .DIFF.FORMAL(P) .INTER. OPT(P) ,NVAR) 
TV(V)  =  .FALSE. 


when  it  only  needed  to  be  computed  once. 
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FIGURE  Bl:  SAMPLE  TRANSFORMATION 
INPUT: 


CONSTANT  NPROC  =  iOO 
CONSTANT  NINV  =  500 
CONSTANT  NVAR  =  1000 
CONSTANT  NSET  =  3000 


C 

C 

C 

C 

c 

c 

c 

G 

c 

G 


SUBROUTINE  ALIAS (LOCAL, FORMAL , OPT , NC ALL , CALLS! , INVOK,NUMP, 

AT, SET , NUMS) 

BIT  VECTOR(NVAR)  LOCAL ( N PROC) , FORMAL ( NPROC ), 0 PT ( NPROC ) 
INTEGER  NCALL(NPROC) , CALLS! (NPROC) ,INVOK(NINV) 

BIT  VECTOR(NPROC)  AT ( N S ET ) , ATB ( N S ET ) 

BIT  VECTOR(NVAR)  SET(NSET) 

BIT  VECTOR(NVAR)  TV 
BIT  VECTOR(NPROC)  TP 
COMMON  /LIST/  L L ST , LARR ( NVAR) 

INTEGER  V, P , R, E 


CALL  INTHSH 

WKP=0 

TP= , EMPTY . 

TV= . EMPTY. 

DO  30  P=1 ,NUMP 
TP(P)= . TRUE. 

CALL  LIST (LOCAL (P) .DIFF. FORMAL (P) . INTER . OPT ( P ) ,NVAR) 
IF  (LLST. EQ . 0)  GO  TO  30 
DO  20  1=1, LLST 
V=LARR( I) 

TV( V) = . TRUE . 

SN=HASH(TV, SET,NUMS) 

TV(V)= . FALSE, 

AT( SN) =TP 
WKP=WKP+1 
WLIST(WKP) =SN 
TP(P)= . FALSE. 


C 


20 

30 
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40  IF  (WKP.EQ.O)  RETURN 
SN=WLIST(WKP) 

WKP-WKP-l 

CALL  LIST(AT(SN) . D IF F , ATB ( SN) ,NPROC) 
ATB( SN)=AT(SN) 

DO  60  I=1,LLST 
P=LARR( I) 

L=NCALL( P) 

K=CALLST(P) 

L=K+L-1 
DO  60  E=K,L 
R=INVOK(E) 

CALL  FOPT(XP, SN, E) 

SNP-HASH(XP , SET, HUMS) 

IF  ( .NOT. ATB( SNP) (R) )  GO  TO  60 

IF  (AT(SNP) .NE. ATB(SNP) )  GOTO  50 
WKP=WKP+1 
WLIST (WKP) =SNP 
50  AT( SNP) (R) = . TRUE . 

60  CONTINUE 

GO  TO  40 
C 

END 
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OUTPUT: 


BLOCKD  DATA  AQOOOl 
COMMON  /AOOOOO/  100000(60) 

DATA  100000(  1  )  /  40000 00 OOOOOOOOOOOOQB/, 100000(2)  /200QOOOOOOO 00 000 
^oooob/,iooooo(3)/iooooooooooooooooooob/ 


DATA  100  0  00  (5  8) /OOOOOOOOOOOOOOOQ0004B/, 100000(59) /OOOOOOOQ 00 0000 
^OOOOOOB/, 100000(60)70000000 00 00 OOOOOOOOIB/ 

END 


SUBROUTINE  ALIAS (LOCAL , FORMAL , OPT , N CALL , CALLS! , INVOK, NUMP , 
*  AT,SET,NUMS) 

C 

INTEGER  LOCAL( 1 7. 100) ,FORMAL(17. 100) ,OPT( 1 7, 100) 

C 


C 

C 

C 


INTEGER  NCALL(  IM)  ,  CALLS!  (LOO)  ,INVOK(500) 
INTEGER  AT(2,3000) .ATB(2,3000) 

INTEGER  SET (17, 3000) 


INTEGER  TV( 1 7) 

C 

INTEGER  TP(2) 

C 

COMMON  /LIST/  L L S T , LARR ( 1 Q Q Q ) 

C 

INTEGER  V,P,R,E 
C 
C 

c 

COMMON  /AOOOOO/  100000(60) 

INTEGER  100003 (17) 

INTEGER  100004(2) 

LOGICAL  100005 
LOGICAL  100006 
C 

CALL  INTHSH 
WKP  =  0 

DO  10000  100000=1  .  2 

10000  TP(IQ0QQ0)=0Q000000000000000000B 

DO  10001  100000=1  .  1  7 

ID- 0.01  Tv(iooooo)  =  ooooQooooooooonoooonB 

DO  10002  P-1 ,NUMP 
I00000=(P-1) /60+1 
I00001=P-( 100000-1) ^60 

T  p (  100000 ) =TP(  100000). OR. 100002  (100001) 

DO  10003  100000-1 , 1 7 

I-QQQ.3  10  0003  (  IQ  0000) -LOCAL  (10  0000,  P)  .AND.  .NOT.  FORMAL  ( 10  0000  .  P)  .AND. 

*  OPT( 100000 . P) 
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call  LIST(I00003, 1000) 

IF  (LLST.EQ.O)  GO  TO  30 
DO  20  I=1,LLST 
V=LARR(I) 

I00000=(  V-1  )  /60-H 
10  OOP l=V-(  10  0000-1  ) ^6  0 

T  V ( 100000 ) =  TV (  100000). OR. 10 00 02(100001) 

SN=HASH(TV , SET , NUMS) 

I00000=(V-1 ) /60+1 
100001=V-( lOOOOO-l ) *60 

TV(I00000)=TV(I00000).AND. .NOT. 100002(100001) 

DO  10004  100000=1.2 

10004  AT( 100000, SN)=TP( 100000) 

WKP=WKP+1 

20  WLIST (WKP) =SM 

30  I00000=(P-1) 760+ 1 

I00001=P-( 100000-1) ^60 

10002  TP(I00000)=TP( 100000). AND. .NOT. 100002(100001) 

C 

40  IF  (WKP.EQ.O)  RETURN 
SN=WLIST(WKP) 

WKP=WKP-1 

DO  10005  100000=1,2 

10005  100004 ( 100000) =AT( 100000, SN) . AND. .NOT. ATB( lOOOOQ . SN) 

CALL  LIST(I00004, 100) 

DO  10006  100000=1  ,  2 

10006  ATB( 100000, SN)=AT( 100000, SN) 

DO  60  I=1,LLST 

P=LARR( I) 

L=NCALL( P) 

K=CALLST(P) 

L=K+L-1 
DO  60  E=K,L 
R=INVOK( E) 

CALL  FOPT(XP , SN, E) 

SNP=HASH(XP,SET,NUMS) 

100000= (R-1 )  /60+1 
I0000l=R-( 100000- 1)^60 

I00005=(ATB( 100000, SNP). AND. 100002(100001) ).NE.O 
IF  ( .NOT. 100005)  GO  TO  60 
100006==  .  FALSE. 

DO  10007  100000=1,2 

10  0  0  7  100  0  06  =  100006. OR. AT (100000,  SNP)  . NE . ATB ( IQ  0000 , SNP) 

IF  (100006)  GOTO  50 
WKP=WKP+1 
WLIST (WKP) =SNP 
50  I00000=(R-1) 760+1 

I0000l=R-( 100000- 1)^60 

ATdOOOOO  ,  SNP)=AT(IOOOOO.  SNP). OR.  100002(100001) 

60  CONTINUE 

GO  TO  40 
C 


END 


n  o 


FIGURE  B2:  BIT  VECTOR  TRANSLATION  SPECIFICATION 


GLOBAL  CONS 

STRING  BIT, ZERO ,UNIV,WRDS , INDEX, INDX2 , ERRS, GLON 
INTEGER  WRDLEN , IKUND , IKSMP , I KARR , IKABV, IKSEL, 

*  IKLHS, IKVAL,IKONE, IKZER, IKCON 

LOGICAL  DECLAR 

END 

C 


START  OF  TEXT 
C 

INCLUDE  CONS 
C 

c 

WRDLEN  =  60 

WRDS  =  $60$ 

UNIV  =  $777777777777777777776$ 

ZERO  =  $000000000000000000006$ 

ERRS  =  $**ERROR**$ 

C 

IKUND  =  1 
IKSMP  =  2 
IKCON  =  2 
I KARR  =  3 
IKABV  =  4 
IKSEL  =  5 
IKLHS  =  6 
IKVAL  =  7 
IKONE  =  8 
IKZER  =  9 
C 

BIT  =  .GEN  I. 

GLOM  =  .GENG. 

EXECUTE  $BLOCK  DATA  $*.GENG. 

EXECUTE  $COMMON  /$*GLON*$/  $  * B I T* $ ( $ * WRD S *  $ ) $ 

DO  20  I-  I  ,  20 
S  =  . EMPSTR. 

DO  10  J=l,3 

ZERO  (I)  ==  .  CONVER.  (  2**  (3-J)  ) 

10  S  =  S*BIT*$  (  $*  ,  CONVER.  (  3*H-J~3)  *$)  /$*ZERO*$/ ,  $ 

ZERO(I)  =  $0$ 

20  EXECUTE  $DATA  $ * S ( 0 ,  .  L ENGTH ,  S ) 

EXECUTE  $END$ 

C 

RETURN 

END 


oo  oooo  nooooo  oo 
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c 

c 

STATEMENT/ N/  $CONSTANT$-,  ID./A--$  =  $-.INT./B 
C 

INCLUDE  CONS 
HEAP  HA 


LOOKUP(GLOBAL)  A  IN  HA 
IF  ( , UNDEF . HA)  GO  TO  10 
EXECUTE  $C0NSTANT  $*ERRS 
RETURN 

10  NEW  HA(2) 

HA( 1 , . INT. )  =  IKCON 
HA( 2 , . STR. )  =  B 
RETURN 
END 


START  OF  UNIT(A) 
INCLUDE  CONS 


DECLAR  -  .TRUE. 

RETURN 

END 


ENTRY 

INCLUDE  CONS 
STRING  S 


INDEX  =  .GENI. 

INDX2  =  .GENI. 

BIT  =  .GENI. 

DECLAR  =  . FALSE. 

C 

DECLARE  $COMMON  /$*GLON*$/  $ * B IT* $ ( $ * WRD S* $ ) $ 

C 

RETURN 

END 


no  oo  oooo 
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STATEMENT/ S/  $ B IT $- $VE CTOR$ -$($«. INT . / A™ $ ) $-L I S T ( . REF. ) /B 

INCLUDE  CONS 
STRING  LENS 


NBIT  =  .INTERP.A 

LEN  =  (NBIT-1 ) /WRDLEN+1 

LENS  =  .CONVER.LEN 

CALL  DECBIT(B, LEN, LENS) 

RETURN 


C 

STATEMENT/ S/  $BIT$™$VECTOR$-$ ( $- . ID./A-$)$-LIST(. REF. ) /B 
C 

INCLUDE  CONS 
STRING  LENS 

HEAP  HA 

C 
C 

LOOKUP(GLOBAL)  A  IN  HA 
IF  ( .UNDEF . HA)  GO  TO  10 

NBIT  =  . INTERP . HA( 2 , . STR. ) 

LEN  =  (NBIT-1) /WRDLEN+1 
LENS  =  . CONVER.LEN 
GO  TO  20 
10  LEN  =  1 

LENS  =  ERRS 

20  CALL  DECBIT(B , LEN, LENS) 

RETURN 

END 


o  o 
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subroutine  DECBIT(B ,LEN, LENS) 

C 

INCLUDE  CONS 
STRING  LENSES 

HEAP  B,HB 

C 

INTEGER  REFERENCE  TRAN 
C 

c 

J  ==  .LENGTH, B 

S  =  .EMPSTR. 

DO  40  1=1, J 

CATCH  B ( I , . STR. )  IN  HB 
IB=TRAN(HB) 

GO  TO  (10, 30, 30, 20, 3 0,30, 30, 30, 30), IB 
10  S  -  S*B(I,  .STR.  )*$($*LENS*$)  ,$ 

NEW  HB(2) 

HB( 1 , . INT. )  =  IKSMP 
HB( 2 , . INT. )  =  LEN 
GO  TO  40 

20  S  =  S*HB(2 , . STR. ) *LENS*$ , $*HB(3 , . STR. ) *$ , $ 

HB ( 1 , . INT. )  =  IKARR 
HB( 2 , . INT. )  =  LEN 
GO  TO  40 

30  S  =  S*ERRS*$,$ 

40  CONTINUE 

DECLARE  $INTEGER  S ( 0 LENGTH . S) 

RETURN 

END 


o  o  o  o  o  o  o 
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identifier  A=*B* 

INCLUDE  CONS 
HEAP  H,HB 

INTEGER  REFERENCE  TRAN 


IF  (DECLAR)  GO  TO  lOO 
C 

LOOKUP(GLOBAL)  B  IN  HB 

IF  ( . NOT. . UNDEF . HB)  GO  TO  40 

LOOKUP  B  IN  HB 

IB=TRAN(HB) 

GO  TO  (30, 10,20,30,30,30,30,30,30) , IB 
10  A  =  B*$ ( $*INDEX*$) $ 

NEW  H(3) 

H( 1 , . INT. )  =  IKLHS 
GO  TO  25 

20  A  =  B*$ ( $*INDEX*$  ,  $ 

NEW  H(3) 

H( 1 , . INT, )  -  IKABV 
25  H(2,.INT.)  =  HB(2,.INT.) 

H(3,.STR.)  =  B 
PASS  H 

30  A  =  B 

RETURN 

40  A  =  HB( 2 , , STR. ) 

NEW  H( 1 ) 

H( 1 , . INT, )  =  IKCON 
PASS  H 
C 

100  A  =  B 

LOOKUPC GLOBAL)  B  IN  HB 
IF  (, UNDEF. HB)  LOOKUP  B  IN  HB 
PASS  HB 
C 


END 


no  o  noon 
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reference  A=*B*(*C*) 

INCLUDE  CONS 
STRING  TL,S 
HEAP 

INTEGER  REFERENCE  TRAN 
STRING  REFERENCE  EVAL 


CATCH  B  IN  HB 
IB  =  TRAN(HB) 

J  =  .LENGTH. C 
IF  (DECLAR)  GO  TO  200 

IF  (IB . GT. IKABV. AND. J. NE. 1)  GO  TO  10 
GO  TO  (70* 10, 10,60,  10,40,50,20,30)  , IB 

10  A  =  ERRS 
RETURN 

20  A  =  $ . TRUE . $ 

RETURN 

30  A  =  $ . FALSE. $ 

RETURN 

40  A  =  B 

HB( 1 , . INT, )  -  IKSEL 

HB(2 , . STR. )  =  B 

HB(3  ,  ,  STR,  )  ==  C(  1  ,  .  STR.  ) 

PASS  HB 

50  A  ==  EVAL(B  ,  C(  1  ,  .  STR.  )  ) 

RETURN 

60  A  =  . EMPSTR. 

DO  65  1=1, J 

65  A  =  A*C(I,.STR.)*$,$ 

A  =  A(0 , .LENGTH. A) *$ ) $ 

HB( 1 , , INT, )  =  IKLHS 
HB(3,.STR.)  =  HB(3  ,  . STR. ) *$ ($*A 
A  =  B*A 
PASS  HB 
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70  A  =  B*$  (  $ 

DO  130  I-1,J 

CATCH  C(  1  ,  . STR.  )  IN  HC 
IC  =  TRAN(HC) 

GO  TO  (  120, 120,  1  10 , 80, 90, 80, 100, 1  10 , 1  10)  ,IC 
80  A  =  A*HC( 3 , , STR. ) *$ , $ 

GO  TO  130 

90  A  =  A*EVAL(HTPC(2,  .STR.)  ,HC(3,  .STR. ))*$,$ 

GO  TO  130 

100  TL  =  .GENI, 

DECLARE  $INTEGER  $* TL* $ ( $* . CONVER . HC  (  2  ,  . INT .  ) *  $ ) $ 
CALL  LOOP(TL*$ ( $* INDEX* $ ) - $*C ( I ,.STR.),HC(2,.INT.)) 
A  =  A*TL*$ , $ 

GO  TO  130 

110  A  =  A*ERRS*$ , $ 

GO  TO  130 

120  A=A*C(I,.STR.)*$,$ 

130  CONTINUE 

A  =  A(0 LENGTH. A) *$) $ 

RETURN 

200  S  -  . EMPSTR. 

DO  210  1=1, J 

210  S  -  S*C(I, . STR, ) *$ , $ 

S  =  S ( 0 ,  .LENGTH.  S)  *$  )  $ 

A  =  B  *  $  (  $  *  S 

IF  ( IB . NE. IKUND)  PASS  HB 
NEW  HB(3) 

HB( 1 ,  . INT.  )  =  IKABV 
HB(2,.STR,)  ==  B*$($ 

HB(3 , . STR. )  =  S 
PASS  HB 

END 


oo  o  oooo  no  oooo 
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ZOP  A=, EMPTY. 

INCLUDE  CONS 
HEAP  H 


A  =  ZERO 
NEW  H(l) 

H( i , , INT. )  =  IKZER 

PASS  H 

END 


UOP  A- . NOT, B 

INCLUDE  CONS 
HEAP  HB 

INTEGER  REFERENCE  TRAN 
STRING  REFERENCE  EVAL 


CATCH  B  IN  HB 
IB  =  TRAN(HB) 

IF  ( IB . NE . IKSEL)  GO  TO  10 
IB  -  IKUND 

B  =  EVAL(HB(2 , , STR. ) ,HB(3 , . STR. ) ) 
10  IF  (IB . EQ. IKUND)  GO  TO  20 
A  =  ERRS 
RETURN 

20  A  =  $.NOT.$*B 
RETURN 
END 


oo  oo  o  oooo 
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C 

C 

G 

C 

c 

c 


BOP  A=B ,AND, (500) C 
STRING  REFERENCE  BOOL 


A  =  B00L(B,$ . AND, $,C) 

RETURN 

END 


BOP  A  =  B . OR.  (  500) C 
STRING  REFERENCE  BOOL 


A  -  B00L(B , $ .OR. $ , C) 

RETURN 

END 


STRING  FUNCTION  BOOL(B,OP,C) 

C 

INCLUDE  CONS 
HEAP  HB,HC 

STRING  B,0P,C 

C 

INTEGER  REFERENCE  TRAN 
STRING  REFERENCE  EVAL 
C 
C 

CATCH  B  IN  HB 
CATCH  C  IN  HC 
IB  =  TRAN(HB) 

IC  =  TRAN(HC) 

IF  ( IB .NE. IKSEL)  GO  TO  10 
IB  =  IKUND 

B  =  EVAL(HB(2 , . STR. ) ,HB(3 , . STR, ) ) 

10  IF  ( IC . NE. IKSEL)  GO  TO  20 
IC  =  IKUND 

C  =  EVAL(HC(2 , . STR. ) ,HC(3 , . STR. ) ) 

20  IF  (IB .LE. IKCON. AND. IC .LE. IKCON)  GO  TO  30 
BOOL  =  ERRS 
RETURN 

30  BOOL  =  B*OP*C 
RETURN 
END 


oo  o  o  o  ooo 
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BOP  A=B ,NE. (400) C 
INCLUDE  CONS 
HEAP  HB,HC 

INTEGER  REFERENCE  TRAN 
STRING  REFERENCE  BOOL 


CATCH  B  IN  HB 
CATCH  C  IN  HC 
IB  =  TRAN(HB) 

IC  =  TRAN(HC) 

IF  ( IB . LE. IKSEL. OR. IC . LE, IKSEL)  GO  TO  50 
IF  ( IB . GE. IKONE)  GO  TO  10 
J  =  HB(2 , , INT. ) 

GO  TO  20 

10  IF  (IC. GE. IKONE)  GO  TO  30 
J  =  HC( 3  ,  . INT.  ) 

20  A  =  .GENI. 

DECLARE  $LOGICAL  $*A 
EXECUTE  A*$=. FALSE. $ 

CALL  LOOP(A*$=$*A*$ .OR,$*B*$.NE.$*C,J) 
RETURN 

30  IF  (IC.EQ.IB)  GO  TO  40 
A  =  $ , FALSE . $ 

RETURN 

40  A  -  $ . TRUE . $ 

RETURN 

50  A  =  BOOL(B , $ . NE. $ , C) 

RETURN 

END 


o  o 
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C 


BOP  A=B . INTER. ( 200) C 
C 

INCLUDE  CONS 
HEAP  HB,HC 

C 

INTEGER  REFERENCE  TRAN 
C 
C 

CATCH  B  IN  HB 
CATCH  C  IN  HC 
IB  =  TRAN(HB) 

IC  =  TRAN(HC) 

IF  (IB.LE.IKSEL.OR.IC.LE.IKSEL)  GO  TO  30 
IF  ( IB . EQ, IKONE. OR. IC , EQ . IKZER)  GO  TO  10 
IF  (IC.EQ. IKONE, OR. IB .EQ.  IKZER)  GO  TO  20 
IF  (HB( 2 , . INT. ) . NE. HG(2 , . INT. ) )  GO  TO  30 
A  =  B*$ . AND. $*C 
HB( 1 , . INT. )  =  IKLHS 
PASS  HB 
10  A  =  C 

PASS  HC 
20  A  =  B 

PASS  HB 
30  A  =  ERRS 
RETURN 
END 


o  o  o  o  o  o  o 
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BOP  A=B .DIFF, ( 100)C 

INCLUDE  CONS 
HEAP  HB,HC 

INTEGER  REFERENCE  TRAN 


CATCH  B  IN  HB 
CATCH  C  IN  HC 
IB  =  TRAN(HB) 

IC  =  TRAN(HC) 

IF  ( IB ,LE. IKSEL . OR. IC .LE, IKSEL)  GO  TO  30 
IF  ( IB . EQ  ,  IKZER. OR. IC . IKZER)  GO  TO  20 
IF  ( IC . EQ , IKONE)  GO  TO  15 
IF  ( IB . EQ . IKONE)  GO  TO  10 

IF  (HB( 2 , . INT. ) . NE. HC( 2 , . INT. ) )  GO  TO  30 


A  =  B*$ . AND . . 

NOT.  $*C 

HB( 1 , . INT. )  = 
PASS  HB 

IKVAL 

10 

A  =  $ . NOT. $*C 

HC( 1 , , INT. )  = 

PASS  HC 

IKVAL 

15 

A  =  ZERO 

HC( 1 , . INT. )  = 
PASS  HC 

IKZER 

20 

A  ==  B 

PASS  HB 

30 

A  =  ERRS 

RETURN 

END 

n  o 
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C 

STATEMENT/E/  . REF . / A- $= $- . EXP . / B 
C 

INCLUDE  CONS 
HEAP  HA,HB 

LOGICAL  LOGT,LOGF 
STRING  C1,TRG,T1,T2 

C 

INTEGER  REFERENCE  TRAN 
C 
C 

CATCH  A  IN  HA 
CATCH  B  IN  HB 
lA  =  TRAN(HA) 

IB  =  TRAN(HB) 

GO  TO  (40, 10, 10, 10, 20, 30,  10, 10, 10)  ,IA 
10  EXECUTE  $ASSIGN  $*ERRS 
RETURN 

20  IF  ( IB . EQ . IKUND)  GO  TO  21 
IF  ( IB .NE . IKSEL)  GO  TO  10 

B  =  EVAL(HB(2 , . STR. ) ,HB(3 , . STR. ) ) 

21  Cl  =  HA( 2 , . STR, ) 

TRG  =  HA( 3 , . STR. ) 

EXECUTE  INDEX*$=( $*C1*$-1 ) /$*WRDS*$+1$ 

EXECUTE  INDX2* $=$*Cl*$-($* INDEX* $" 1 ) *$*WRDS 
LOGT  =  B . EQ , $ . TRUE , $ 

IF  (LOGT)  GO  TO  22 
LOGF  -  B . EQ, $ . FALSE. $ 

IF  (LOGF)  GO  TO  23 
T1  =  .GENL. 

T2  -  .GENL. 

EXECUTE  $IF  ($*B*$)  GO  TO  $*T1 

22  EXECUTE  $  $ *T RG* $ - $ *TRG* $ . OR . $ * B I T* $ ( $ * INDX 2 *  $ ) $ 

IF  (LOGT)  RETURN 

EXECUTE  $  GO  TO  $*T2 
LABEL  T1 

23  EXECUTE  $  $ * T RG* $ - $ *T RG* $ . AND , . N OT . $ * B I T* $ ( $ * INDX 2* $ ) $ 
IF  (LOGF)  RETURN 

LABEL  T2 
RETURN 

30  GO  TO  (  10 , 10 ,  10 , 10 , 10 , 3 1 , 3 1 , 32 , 32)  ,  IB 

31  IF  (HB( 2 , . INT, ) . NE . HA( 2 , . INT. ) )  GO  TO  10 

32  CALL  LOOP (A*$=$*B ,HA( 2 , . INT, ) 

RETURN 

40  GO  TO  (50,50, 10  ,  10,45  ,  10, 10, 10, 10)  , IB 
45  EXECUTE  A* $=$*EVAL ( HB ( 2 , . STR. ) , HB ( 3 , . STR. ) ) 

RETURN 

50  EXECUTE  A*$=$*B 

RETURN 


END 


oo  oooo  oo  nnooo  oo  oon 
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C 


SUBROUTINE  L 00 P ( S T R , L EN ) 

INCLUDE  CONS 
STRING  STR,LAB 


LAB  =  .GENL. 

EXECUTE  $D0  $*LAB*$  $* INDEX* $  =  1 ,$*, CONVE R  ,  L EN 

LABEL  LAB 

EXECUTE  $  $*STR 

RETURN 

END 


STRING  FUNCTION  EVAL ( STRB , STRC) 

INCLUDE  CONS 
STRING  STRB, STRC 


EVAL  =  .GENI. 

DECLARE  $L0GICAL  $*EVAL 

EXECUTE  INDEX* $=($* STRC* $-1) /$*WRDS*$+1$ 

EXECUTE  INDX2*$-$*STRC*$-($*INDEX*$-1 ) *$*WRDS 

EXECUTE  EVAL* $=($* STRB* $ .AND. $*BIT*$($*INDX2*$)) .NE.0$ 

RETURN 

END 


INTEGER  FUNCTION  TRAN(HP) 

INCLUDE  CONS 
HEAP  HP 


TRAN  =  IKUND 
IF  (.UNDEF.HP)  RETURN 
TRAN  -  HP( 1 , . INT. ) 
RETURN 
END 


$ 


